【技術書の読書術 実践してみた】3の発想で3冊の本を読んでみた

こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。

突然ですが技術書を読む際に以下のような悩みが頭をよぎりませんか？

• この本に書いてあることは世間一般的に見ても正しいのだろうか？
• この書籍で語られているどの部分が特に重要なのだろうか？
• この本にはこう書いてあるけど本当かなぁ？私は違う気がするけど根拠がないなぁ

私はよく思います。

そこで「技術書の読み方」自体も勉強したいなぁと考えていたところ、書店でこちらの本を発見しました。

この本を読んだ時に「3の発想」という素敵な考え方を知ることができたので、今回実際に実践してみました！

ITエンジニアの方に限らず、いろいろな分野の読書にも応用が効きそうだと思いますので、どなたかの参考にでもなればうれしいです！

3の発想とは？

書籍内にも記載されていますが、こちらの記事でも考え方が紹介されています。

もともとの考え方は「3」の発想 数学教育に欠けているものという書籍で紹介されているようです。

「２」の発想の場合、積み木でいえば、Aが倒れかかってくればBも倒れてしまう。(中略）2つの関係だから、その先に思考が及ぶことはない。AとBの完結した世界である。一方、「3」の発想を考えてみると、積み木でいえば、３つ存在することである、まず、Aが倒れかかってくればBも倒れる。Bが倒れれば、次にあるCも倒れてしまう。ドミノ倒しの最小、「A→B→C」の連鎖である。「A→B」となり、「B→C」となれば、多分「C→D」と人は考える。完結しない世界、連鎖する世界、である。

私（この記事の著者）としては 多分「C→D」と人は考えるの部分が重要なのかなと感じました。

「３人もの（技術書を書くような）凄い人が言っているし、僕も自信を持って後輩にもこのテクニックを紹介できるな」と思えますし、それぞれの本で述べられている重要なエッセンスを汲み取りやすくなる気がしませんか？

逆に1冊でしか述べられていないことでも、「この著者が考えている比較的新しい考えなのかもしれないから、もう少し詳しく調べてみよう」というきっかけになるかもしれませんし、よく考えれば他の本でも本質的には同じことを言っていることを理解できるかもしれません。

この本では3の発想に基づいて以下のように視点が異なる本を3種くらい読むことで実務で使えるレベルになるでしょうと述べられています。

• 1冊目： 入門レベルの本
• 2冊目： 専門書
• 3冊目： 逆引き

他にも入門書3冊を読み比べてみるなど、3の発想はいろいろな考え方の応用がありそうです。

私としては「3冊以上を「この本ではこう言っている」「あっ！これこの前の本でも言ってた！」などとノートなどの媒体にまとめる方法が良さそうだなと感じました。

ということで実際にやってみました！

今回読んだ3冊の書籍

今回のテーマを「良いコードの設計・書き方」と設定して、以下の書籍を選んでみました。

選定理由： 前の職場でも何人ものベテランが新人エンジニアに推薦していた。読んだ時に今の自分のレベルなら、あまり苦労なく読めそうであったため。

選定理由： 著者の作成していた動画（例えばこちら）をよく見ていました。以前も読んだことがあったのですが、アウトプットや実践ができておらず内容を忘れていたため。

選定理由： 普段は読むのが重そうな書籍を3冊目に持ってきたかったため。また、現在OSSへのコントリビュートをしている中でリファクタに関心があったので。

私なりのやり方

Notionでまとめてみる

今回3冊の本の内容をまとめるにあたって以下の点が重要と考えました。

• どの本に書いてあったか分類しやすい
• 実際のコード例とかを気軽に書き込みができる
• カンバンボードのように特定のカテゴリを視覚的に分かりやすくまとめたい

これらを考慮して、業務でも使用しているNotionを利用してみることにしました。

本を読みながら「なるほど！」「これは良い！」「あぁ。そういうこと？」「完全に理解した（してない）」と思ったことを書き出していきます。

以下のように雑にカテゴリ分けしながら、ボード風にまとめていきました。

どの書籍に書いてあったか分かるようにマルチセレクトの「書籍」というプロパティを保持しています。

また、上記の画像のように「んっ？」「じゃあこういう時はどうなの？」「でも、違くない？」と思ったことは、メモしていくようにしています。（参考記事リンクなども込みで）

微妙に違うテーマを扱う本があったら？

たとえば「現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法」はコード周りだけでなく、データベース設計や画面設計のことも触れられています。

そのため、以下のように1冊にしか登場していないトピックも出てきます。

そんな時も読み飛ばさずに記録しておくことで、今度は「よーし！データベースの設計をテーマに本を読むぞ！」となった時に利用できます。

「そもそもこの本だけ、全然違うテーマだった」と気付いた場合は、素直に違う本を買い直せば良いな〜と感じました。

やってみた感想・Tips

感じたメリット・デメリットをまとめてみました。

メリットに感じた・よかったと思った点

• 「あ！3冊に出てくるってことはこの考え方間違っていないかな」と自信が持てた
• 「あの本にはどんな書き方されてたっけなぁ？」と比較しながら読むと面白かった
• 言い回しや使われている用語が違っても「本質的には同じことを言っているかも」と反芻しながら読むことができた
• 普段は読むのが重い本も関連書籍を読んでいるのでいつもより読みやすく感じた
• 手を動かし、アウトプットもすることで理解度がぐんと上がる

「ただ読むだけ」、「なんとなく蛍光ペンを引くだけ」というやり方よりも非常に理解が深まった気がしています！

特にNotionを利用したのは正解だったと感じていて、以下のようなメリットを享受できました！

• Notionを使ってよかったこと
  • 手書きのノートよりも気軽に編集できる
  • ボードで関連トピックを視覚的にまとめられる
    • カテゴリー自体の編集も簡単なので手書きより捗った
  • ページに長文をメモできる（コードも書ける）
  • 当然ネットで調べた記事のリンクも保持できるので、考えの整理によかった

デメリットに感じた点

3冊を何度も見返しながら読むので時間がかかる

これにつきますが、逆に言えばこれだけでした。

しかし理解度の深さが普通に読むよりも良かったのでトータル的なコスト（後でまた実物の本をパラパラ見返したり）を考えると、むしろお得なのかもしれません（Notionにまとめているので検索もできますし）。

この方法が合っていそうな方について

私なりに以下のような方はぜひ一度試してみると良いかなと感じました。

• 1つのテーマについて早く実践レベルになりたい方
• 時間が逼迫していない方
  • 内容次第ですが3冊読むのに最低でも1月くらいはかかると思います

私個人としても今回の活動で「このテーマも深掘りしてみたいなぁ」というテーマが見つかったので、今後も自分なりのペースで進めてみたいと思います。

Tips

以下、私なりのTipsです。

• 最初の1冊目は背伸びしない
  • パラパラっと読んで「あぁ。たしかにそうですね」と思うところが最低でも3割はある方が良いと思います
  • 最初に背伸びすると挫折する可能性が高そうです
• 2冊目または3冊目に背伸びしてみる
  • 個人的には3冊目にがっつり背伸びした書籍でも良いと思います
  • 2冊目から重すぎると、「3冊目はもう嫌だ」となる可能性が上がりそうです
• アウトプットする媒体について
  • 関連するテーマを視覚的に近くにまとめられるものが良さそうです
  • 後で読み返すことも加味して、キーワード検索可能な媒体が良いと思います
• 1日の早い時間に読書をする時間を確保する
  • 私の場合朝活に組み込みました
  • 仕事終わりなどはとても疲れているので、極力朝にやってしまう方が良いと思います
• 読めない日もある。自分を責めないで良い。
  • 生きていれば予定通りに行かないことの方が多いと思います
  • ストイックになりすぎず、明日から再開すればOKだと思います！

最後に

3の発想・技術書の読書術について気になられた方は、ぜひこの書籍を読んでみると良いと思います（再掲）

この記事が誰かの参考になること、誰かの時間を数秒でも縮めることにつながれば嬉しいです！

以上今泉でした。